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ABSTRACT 

A model of program development and evaluation was 
developed at Genesee Community College, utilizing a system 
tneory/process of deductive and inductive reasoning to ensure 
coherence and continuity within the program. The model links 
activities to specific measurable outcomes. Evaluation checks and 
feedlDack are built in at various levels so that program changes can 
be made without redesigning the whole program. The model consists of 
the following siK steps j (l) define the purpose of the course or 
program? (2) identify three to six general activities which will 
achieve the defined purpose? (3) break down each activity to three to 
six more specific activities, making sure that the outcomes remain 
consistent? (4) continue to breakdown the activities to new levels of 
specificity until all activities are clearly defined and understood? 
(5) identify all input and output at each level of activity? (5) 
determine relationships among the activities? and (7) identify 
constraints, such as attitudes, policies, and funding, which 
influence outcomes. The completed model should be check^sJ to ensure 
that activities and outcomes are properly matched at each level and 
that all outcomes are clearly defined in measurable, behavioral 
terms. Graphic depictions of these steps are appended. (WJT) 
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PROGRflM DEVELOraEOT? AND EVMUIATIQN: A MODELING PROCESS 



This model uses a system theory/process, of deductive and inductive 
reasoning with built in checks to ensure coherence and continuity. The 
development process builds in evaluation checks at various levels in the 
fonn of feedback so that changes in the program can be made without 
redesigning the total program. The model links activities to specific 
outcomes and stresses measurability of outcomes. The logical format of the 
model makes it appropriate for use in large programs (complex) as well as 
individual courses. 

When considering program inputs (in this case students), various levels of 
inputs^ must be considered in relationship to each other and to the whole 
itK^del. Many times, outcoiftes for certain transactions ^ or combinations of 
outcomes become the input for subsequent transactions* 

Considerations should be given to the power of each transaction in relation 
to complexity, time allotted for the transaction, input, and constraints. 
Each level of transactions defines clearly a context of activity* The 
relationships between and among transactions on the same level must be 
clearly defined in the same way as the relationships between and among 
levels of transactions. The major concerns with outcomes include 
measurability and logical fit with the characteristics of the input (i.e. 
skill level of students) and the power of individual transactions (i.e. 
ensuring that a one hour lecture has not been identified as causing major 
behavioral changes). 

*This paper and the illustrations are adaptations of Structured Analysis 
and Design Technique (SADT) • The application of this technique to social 
and behavioral sciences was developed by Gary Borich(1982) • 
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Beginning the Modeling Process 

The first step is to define the purpose of the course or program. The 
goals/objectives are very general at this level. This first step will 
provide the most general context encompassing ail program activities. The 
purpose is to clearly define the final outcome of the program from which 
specific subsequent activities and outcomes will be developed {see figure I). 
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At the same level of generality^ choose three activitr.es which will bring 
about the purpose defined earlier (more activities/ transactions may be 
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added if needed) • These activities are very general at this time, they 
are to be arranged to provide continuity and coherence within the program. 
The transactions will be stated as verbs. Look to ensure that the outcome 
of these transactions is the same ending outcome as the previous level (see 
figure 2)* Define the inputs and note all variables which have impact upon 
the input. These variables may constitute important constraints upon the 
identified transactions and therefore should be noted early in the model. 

FIGURE 2 
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The next step is to break down each of the three activities (transactions) 
into three more transactions ♦ Remember that when breaking down 
transactions to a more specific level, that the outcomes must remain 
consistent, i.e. the ending outcome of transaction k is the same as the 
ending outcome of A^e and A^^ (see figure 3). 

After checking the relationships between and among transactions, make sure 
the output is at the same level of specificity as indicated by the 
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transaction (the intensity of activity should match the measurable 
outcome)* Aiso^ ail outcomes must match as you move from level to 
level. Continue to break the model down until the activities and inputs 
are no longer meaningful or measurable. 



FIGURE 3 




Keep in mind the level of generality you're working with each time you go uo 
a more specific level* Furthermore, the time commitment for each transaction 
becomes smaller as it is broken down into its functional components (smaller 
transactions). Interlock with a numerical code each transaction so you can 
identify its place in the larger model (see figure 4), 
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Checking the Hodel 

Check: to see that all inputs and outputs have been identified at each level 
and are congruent with the deductive level at each step* The outcomes should 
remain the same for clusters of transactions which are functional components 
of higher level transactions* State outcomes in measurable terms. The 
inputs at each level should remain consistent to its preceding level's 
output. Check to see that the proper outputs have become the proper inputs 
as the model moves toward more specificity. 

Interrelationships among and between transactions on a single level must be 
indicated* Often there is no strong interrelationship among transactions 
(see figure 5). In this case^ the three transactions provide activities 
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separately which cause a main output. If the transactions are to take place 
sequentially, make sure to note the sequence (see figure 6). This could be 
the case of taking beginning algebra before intermediate^ or having 
composition I before coaqposition II* 
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FIGURE 6 
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The ne« step is to Identify constraints. Constraints „«y include variables 
Which aid or hinder the transaction or out=o,:». Constraints should follow 
the level of generality or detail identified by the appropriate transaction. 
Constraints will be identified with each transaction at each level (see 

figure 7)» 
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There are often Inputs which influence transactions and outcomes that have 
not been identified until later in the model. For exainple, these inputs can 
be additional materials or human resources. If additional inputs are added, 
they must be critical to the transaction and hence the outcome. These inputs 
become important during evaluation because the success of the output can be 
effected due to their absence. 

Feedback 

There are two main feedback mechanisms which can fit into the model. These 
mechanisms serve to ensure program success by noting outconies and sending 
information back to the proper transaction for needed adjustments. One 
type of feedback occurs when an outcome has not been reached by a single 
participant. The participant, when identified, goes back through the 
transaction until the desired outcome is reached (competency based 
program) . Another source of feedback occurs when information from one 
transaction goes back to a subsequent transaction in the form of a 
constraint. An example would be the lator identification of material which 
effects the understanding of material presented earlier in the program in 
such a way to be confusing or the identification of information left out. 
This type of feedback may be used to identify additional inputs or constrains 
relating to prior transactions. An example of this may be the discovery of 
, the need of additional workbooks, materials, knowledge or skills which 
logically fit into an earlier transition. 

Also, if the total output of a higher level set of transactions proves to be 
less than what is desired, this information is routed to lower level 
transactions where program designs at very specific levels can be adequately 
altered. 

9 



8 



In checking tha completed modal, careful attention should be paid in ensuring 
that transactions and outcomes are properly snatched at each level and that 
all outcomes are clearly defined in measurable/behavioral terms. When the 
model is complete, consideration should be given to the qualifications needed 
by those conducting the transactions and to the transactional environment; 
including but not limited to needed resources, and physical and psychosocial 
environment. As a final note, specif iv^ skill levels, motivational levels, 
and psychosocial factors of beginning students should be addressed in the 
initial input phase and thereafter throughout the various levels. 
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PROGRAM DEVELOPMENT 
AND EVALUATION 



A GRAPHIC MODEL 
WHICH WILL AID IN: 

1 CLARIFYING PROGRAM OBJECTIVES 
S IDENTIFYING PROGRAM ACTIVITIES 
3 SPECIFYING PROGRAM OUTCOMES 
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GENERAL SYSTEMS THEORY 
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MODEL BUILDING 
Moving from general to specific 
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BASIC COMPOISIENTS 

I. TRjVNS ACTIONS : Basic building blocks. Program 

activities — Iiabeled with ACTIVE VERB 
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INPUTS ; Activities act upon these things (STUDENTS, STAFF) 

III. OUTCOMES ? Things " produced " --STUDENTS STAFF with certain skills 

IV. CONSTRAINTS : Things which influence outcomes. 

(Funding, facilities, previous behaviors) 

Constraint 
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Participants ji^ 

to be I I Outcome First 

of A constraint 

on C 



provided the 
program 
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of B 



Second 
constraint 
on C 
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Main outcome 
to be attained 
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LET.S DO IT! 

STEP i 

DEFINE PURPOSE OF WHOLE PROGRAM 

i.e. Competent legal assistants 

Students competent in automated 
manufacturing t;ecii. 

Competent Dental Lab Assistants 
A phrase tiiat concisely states purpose 

" R 
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LET,S DO IT! 



IDENTIFY THREE TO SIX 
GENERAL ACTIVITIES 



tsransaclsion 
A 



transaction 



transaction 
C 
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L.ET,S DO IT! 

STEP 1 

DEFINE PURPOSE OF WHOLE PROGRAM 
i.e. Competent; legal assistants 

Students competent in automated 
manufacturing tech. 

Competent Dental Lab Assistants 
A phrase that concisely states purpose 



STEP 2 



IDEIMTIFY THREE TO SIX 



tsran9act;ion 
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tsransaolsion 



«ranaaet;ian 
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TAKE EACH PREVIOUS TRANSACTION 
AND IDENTIFY THREE TO SIX NEW 
TRANSACTIONS FROM EACH 






Continue to form new transactions untii all 
activities are clearly defined and understood. 
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HOW SPECIFIC IS ENOUGH? 

^^^r k!9 h 

bVEm T ^3 ■ 

1. Your Models become hypotheses - If thiSp 
tshen tthet# 

8. Times Tiransaotions take less time and 
become more clearly defined as you 
move down 

3. Stop the process when new transactions no 
longer contribute in meaningful ways to your 
stated terminal outcomes 

4. The breakdown should end when the trans- 
actions fail to produce measurable outcomes 
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STEP4. IDENTIFY INPUT AND OUTPUT 
ON EACH LEVEL OF TRANSACTIONS 



(not each transaction) 



Participants 
being provided 
the program 



(Main input) 




B 



Behavior or 
condition 
participants are 
expected to 
attain (Main 
output) 
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STEP 5. DETERMINE RELATIONSHIPS 

AMONQ TRANSACTIONS 

A. SEQiUENCE 



Participants 
being 



provided 
the program 




Outcome of A 
is input to B 




Outcome of B 
is input to C 




Main outcome 

to be 
attained 
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IF TRANSACTIONS ARE IN SEQUENCE 
THE MAIN OUTCOME IS THE SAME 
AS THE LAST TRANSACTIONS 




Outcome (A) 




Outcome (B) 




Outcome (C) 



This outcome should be 

labeled outcome (C) , 

whose underlying sources 

of variation are outcomes 

(A) and (B) and transaction C. 



MIXED SEQUENCE 
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provided the 
program 




Outcome of A 
is input to B 
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Outcome of B is not 

input to C but contributes 

to main outcome 



Outcome of C 
contributes 
to main 
income 




Main outcome 
to be 
attained 



CHECKING OUTCOMES 



When there is no sequence of transacblons 
the main outcome is different from the 
outcome of theindividual transactions: 




Outcome (A) 
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Outcome (B) 




Outcome (C) 




This outcome should 
be labeled as a 
higher-order construct 
whose underlying 
sources are (A) , (B) , (C) • 



C. NQ SEGIUENCE 
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Outcome of A 
contributes to 
main outcome 




Outcome of B 
contributes to 
main outcome 




Outcome of C 
contributes to 
main outcome 



Main outcome 
to be attained 



UNDERSTANDING CHECK 

NOTICE the outcome of the first level 

NOTICE that the outcome of number 2 Level I 
is the same as the outcome of Level II 

These transactions are 




Level II 
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STEPS. IDENTIFING CONSTRAINTS 
CThose things that: influence outcomes! 

Attitudes Aptitudes Policies 

Regulations Funding 

label each constraint consistent with 
the level of detail at which the trans 

aclsion is described 
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First 
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Outcome 
of B 



Second 
constraint 
on C 




Main outcome 
to be attained 



CHECKIIMO YOUR MODEL 
1 Can each t:ransact;ian be observed? 

8 Can outcomes be stsated as 
operalsional definitions? 

3. Have ail important constraints 
been identified? 

4. Are transactions r id outcomes 
labeled consistently? 

5. Are there logical mismatches bstween 
transactions and outcomes? 

Activity implied by transaction too little to produce outcome? 
Activity is more than what is needed? 

B. Are there missing transactions 
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or outcomes? 

More instruction needed? 
Bridges in transactions? 
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